Big ambiguity in this process is how we get from Submitted to Finalized. Should we be defining voting windows (who decides if a vote is initiated?)

We also dont want Lazy Consensus to mean PRs with no approvals or interactions from any Code Owners are approved. Maybe we need to caveat it saying every Proposal PR needs a Code Owner approval.

alternatively maybe it's okay to leave it less-well-defined, we just make sure it's clear what the merge conditions are and don't define how to get there,

I think, though worth documenting, that code owners are implicitly bound by the decision making process and thus are obliged to merge a change if it passes the vote.

Having said that, I'm not sure we should really use the term code owners in this repository as its really org rules, it should be something like org owners. The Project board? Raising too many questions.

yeap this would be my first Proposal after this :) I think we should define a Commiter/Code Owner (technical steward) and Maintainer (project governor) split.

thinking on this. Since most proposals would likely have some back-and-forth and edits before they are acceptable. Maybe we do need a signal that the "vote" or beginning of lazy consensus has begun. Maybe it should say something like "A Code Owner declares the decision period has begun, at which point our Decision Making Process begins".

This eliminates my other concern that anyone could create a PR, have it sit idle for some weeks, and claim it was accepted by lazy consensus.

have pushed that up. we don't redefine any decision making rules, just say a Code Owner has to declare that a Decision Making Period has begun.

I think collision detection needs to be eager rather than on merge. We don't want people discussing GIP-012 and that potentially referring to two different things.

Also if we think about how this works in Kafka the number is allocated eagerly regardless of outcome.

yep the ids are definitely a pain, not sure what would be a cheap fix, create an issue first and use the issue number? Have an action workflow that checks your id is unique across PRs? Create PR with placeholder than edit in the PR number.

decided in call to leave id selection as a Proposer responsibility, we don't anticipate a flood of these.

I think the process as described is eager, you pick a unique id at Proposal creation time. The note tells you what to do if you mess it up, update the id in the newer PR.

I think we need to finalise either way even if rejected we should merge - to prevent ID recycling.

mm, bit of a fiddle, the proposal is decision record and edits to the canonical Governance files come in the same PR. So you'd have to split out just the decision record.

was pondering whether we should split them into proposal PR and then after approval make the edits in another PR. but it feels like they're good to land in a single PR, proving that our policy changed exactly in lockstep with accepting a proposal and avoiding having to vote on the proposal and then the implementation.

if we used the PR # (at the cost of some hassle editing it in after creation) then we don't have this recycling problem.

mm, bit of a fiddle, the proposal is decision record and edits to the canonical Governance files come in the same PR. So you'd have to split out just the decision record.

When you put it like that I think the case for merging all is even stronger. Its record of the decision not to make a specific change. We should merge that so we have a higher bar for re-visiting a particular decision, e.g. expressing some rational for what has changed since the last record.

I think we can configure haus-rules to help with this.

Though I think we might need to be a little careful with eager votes. I.e. clear votes on significant re-draft. Or when voting is re-opened.

Are we saying lazy consensus applies to GIPs too, with us only resorting to votes when required? I think that follows the 'light weight' spirit of Common Haus. If it is a decided a vote needs to occur on a particular GIP who gets to vote? All active contributors- or a smaller sub-set?

Yes, I think we have defined already that Lazy Consensus is step 1 of our general decision making process, It would be good if we could avoid redefining that part, and just have this GIP process point to our general decision process.

But as a guard rail, I think that a Code Owner should have to declare that the Decision Making Period is open for a GIP. This means that Proposals would need to get a Project member on board.

We possibly need to refine our voting rules. They currently only give code owners any voting rights.

yeahp, bit of chicken and egg. I was spurred to make this PR by wondering how we could introduce different roles or change the voting rights.

I don't think thats a bad outcome of this PR. We use the currently documented process to endorse a version of this and then expand the franchise etc.

As a title it works, but I'm not really liking GIP, I know it echos KIP but we can't really re-use KIP either.

some options:

• KRoxylicious IMprovement Process KRIMP.
• Kroxylicious Governance IMprovement Process KGIMP

Should Governance Changes have a higher bar? I think it would be a bit dodgy if a single Code Owner could change some aspect of Governance with just their own approval.

Yes, definitely but we already define voting as simple majority. So maybe governance changes skip lazy consensus and go direct to vote?

was thinking on this as I've commented elsewhere. It would be nice to use the general Decision Making process without having to diverge. Maybe Lazy Consensus as a step 1 is fine, as long as a Code Owner is responsible for declaring when the Decision Making Period is open. So it's visible and we need someone within the Project on-board.